Frontend Service Meshi kaitselüliti: Rikete isoleerimise meisterlik valdamine vastupidavate globaalsete rakenduste jaoks

Tänapäeva omavahel ühendatud digitaalses maastikus on esmatähtis ehitada rakendusi, mis pole mitte ainult jõudsad, vaid ka märkimisväärselt vastupidavad riketele. Kuna mikroteenuste arhitektuurid muutuvad skaleeritavate ja agiilsete süsteemide arendamisel de facto standardiks, kasvab teenustevahelise suhtluse haldamise keerukus eksponentsiaalselt. Üksiku rikkepunkti tekkimine ühes teenuses võib põhjustada ahelreaktsiooni, mis viib terve rakenduse rivist välja. Just siin kerkib kaitselüliti muster (Circuit Breaker pattern), kui see on rakendatud frontend service meshi kontekstis, esile kui oluline tööriist robustsuse ja sujuva degradeerumise tagamiseks. See põhjalik juhend süveneb frontend service meshi kaitselüliti keerukustesse, selle olulisusesse, rakendusstrateegiatesse ja parimatesse tavadesse, et saavutada oma globaalsetes rakendustes tõeline rikete isoleerimine.

Hajutatud süsteemide vastupidavuse kasvav väljakutse

Kaasaegsed rakendused on harva monoliitsed. Tavaliselt koosnevad need paljudest väiksematest, iseseisvatest teenustest, mis suhtlevad omavahel võrgu kaudu. Kuigi see mikroteenuste lähenemine pakub mitmeid eeliseid, sealhulgas sõltumatut skaleeritavust, tehnoloogilist mitmekesisust ja kiiremaid arendustsükleid, toob see kaasa ka omaseid keerukusi:

• Võrgu latentsus ja ebausaldusväärsus: Võrgukutsed on olemuselt vähem usaldusväärsed kui protsessisisesed kutsed. Latentsus, pakettide kadu ja vahelduvad võrgupartitsioonid on tavalised nähtused, eriti geograafiliselt hajutatud teenustega globaalsetes juurutustes.
• Ahelrikked: Rike ühes allavoolu teenuses võib käivitada rikete laine ülesvoolu teenustes, mis sellest sõltuvad. Kui seda korralikult ei hallata, võib see viia süsteemi täieliku seiskumiseni.
• Ressursside ammendumine: Kui teenus on ülekoormatud või ebaõnnestub, võib see tarbida liigselt seda kutsuvate teenuste ressursse (protsessor, mälu, võrgu ribalaius), süvendades probleemi.
• Sõltuvused: Teenuste vahelise keeruka sõltuvuste võrgustiku mõistmine ja haldamine on monumentaalne ülesanne. Rike pealtnäha väikeses teenuses võib omada kaugeleulatuvaid tagajärgi.

Need väljakutsed rõhutavad tungivat vajadust robustsete mehhanismide järele, mis suudavad rikkeid varakult tuvastada, takistada nende levikut ja võimaldada süsteemil sujuvalt taastuda. Just seda probleemi püüab kaitselüliti muster lahendada.

Kaitselüliti mustri mõistmine

Inspireerituna elektrilistest kaitselülititest, toimib kaitselüliti muster proksina kaugeteenusele tehtavatele kutsetele. See jälgib rikkeid ja kui teatud lävend on saavutatud, 'lülitab' see vooluringi välja, takistades edasisi kutseid ebaõnnestuvale teenusele teatud aja jooksul. See takistab klientidel raiskamast ressursse päringutele, mis on määratud ebaõnnestuma, ja annab ebaõnnestuvale teenusele aega taastumiseks.

Muster töötab tavaliselt kolmes olekus:

1. Suletud olek

Suletud olekus lubatakse päringutel kaitstud teenusesse läbi minna. Kaitselüliti jälgib ebaõnnestumiste arvu (nt ajalõpud, erandid või selgesõnalised veavastused). Kui ebaõnnestumiste arv ületab teatud ajaaknas konfigureeritud lävendi, läheb kaitselüliti üle Avatud olekusse.

2. Avatud olek

Avatud olekus lükatakse kõik päringud kaitstud teenusele kohe tagasi, ilma et proovitaks teenust kutsuda. See on ülioluline mehhanism, et vältida edasist koormust ebaõnnestuvale teenusele ja kaitsta kutsuva teenuse ressursse. Pärast konfigureeritud ajalõpu perioodi läheb kaitselüliti üle Pooleldi avatud olekusse.

3. Pooleldi avatud olek

Pooleldi avatud olekus lubatakse piiratud arvul testpäringuid kaitstud teenusesse läbi minna. Kui need testpäringud õnnestuvad, näitab see, et ebaõnnestunud teenus on võinud taastuda, ja kaitselüliti läheb tagasi Suletud olekusse. Kui testpäringud jätkuvalt ebaõnnestuvad, naaseb kaitselüliti kohe Avatud olekusse, lähtestades ajalõpu perioodi.

See olekupõhine mehhanism tagab, et ebaõnnestuvat teenust ei pommitata pidevalt päringutega, kui see on maas, ja see üritab arukalt taastada ühenduse, kui see võib taas kättesaadavaks muutuda.

Frontend Service Mesh: Ideaalne keskkond kaitselülitite jaoks

Teenustevõrk (service mesh) on spetsiaalne taristukiht teenustevahelise suhtluse haldamiseks. See pakub viisi, kuidas kontrollida mikroteenuste ühendamist, jälgimist ja turvamist. Kui abstraheerite suhtlusloogika teenustevõrku, saate tsentraliseeritud punkti läbivate funktsioonide, nagu koormuse tasakaalustamine, liikluse haldamine ja, mis on kriitiline, vastupidavusmustrite, näiteks kaitselülitite, rakendamiseks.

Frontend service mesh viitab tavaliselt teenustevõrgu võimekustele, mis asuvad teie teenusmaastiku serval, sageli hallatuna API lüüsi või Ingress Controlleri poolt. See on koht, kuhu välised päringud esmalt teie mikroteenuste keskkonda sisenevad, ja see on parim asukoht vastupidavuspoliitikate jõustamiseks enne, kui päringud isegi sisemiste teenusteni jõuavad. Alternatiivselt võib termin viidata ka kliendipoolsesse rakendusse endasse paigaldatud teenustevõrgule (kuigi see on puhtalt mikroteenuste kontekstis vähem levinud ja sarnaneb pigem teegipõhisele vastupidavusele).

Kaitselülitite rakendamine frontend service meshis pakub mitmeid kaalukaid eeliseid:

• Tsentraliseeritud poliitika jõustamine: Kaitselüliti loogikat hallatakse tsentraalselt teenustevõrgu proksis (nt Envoy, Linkerd proxy), selle asemel et see oleks jaotatud üksikute mikroteenuste vahel. See lihtsustab haldamist ja vähendab koodi dubleerimist.
• Vastupidavuse eraldamine äriloogikast: Arendajad saavad keskenduda äriloogikale, ilma et peaksid igasse teenusesse keerukaid vastupidavusmustreid sisse ehitama. Teenustevõrk tegeleb nende küsimustega läbipaistvalt.
• Globaalne nähtavus ja kontroll: Teenustevõrk pakub ühtset platvormi teenuste seisundi jälgimiseks ja kaitselüliti poliitikate konfigureerimiseks kogu rakendusmaastikul, hõlbustades globaalset vaadet vastupidavusele.
• Dünaamiline konfigureerimine: Kaitselüliti lävendeid, ajalõppe ja muid parameetreid saab sageli dünaamiliselt uuendada ilma teenuseid uuesti juurutamata, võimaldades kiiret reageerimist muutuvatele süsteemi tingimustele.
• Järjepidevus: Tagab järjepideva lähenemise rikete käsitlemisele kõigis võrgu hallatavates teenustes.

Kaitselülitite rakendamine Frontend Service Meshis

Enamik kaasaegseid teenustevõrke, nagu Istio, Linkerd ja Consul Connect, pakuvad sisseehitatud tuge kaitselüliti mustrile. Rakendamise üksikasjad varieeruvad, kuid põhimõisted jäävad samaks.

Istio kasutamine kaitselülitite jaoks

Istio, populaarne teenustevõrk, kasutab Envoy proksisid, et pakkuda täiustatud liikluse haldamise funktsioone, sealhulgas kaitselülitust. Kaitselülituse reeglid defineeritakse Istio `DestinationRule` ressursi abil.

Näide: `product-catalog` teenuse kaitsmine

Oletame, et teil on `product-catalog` teenus, mis kogeb vahelduvaid rikkeid. Soovite konfigureerida kaitselüliti Istio Ingress Gateway's (mis toimib frontend service meshi komponendina), et kaitsta oma kliente nende rikete eest.

            apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: product-catalog-circuitbreaker
spec:
  host: product-catalog.default.svc.cluster.local # Kaitstav teenus
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5  # Lülita vooluring välja pärast 5 järjestikust 5xx viga
      interval: 10s          # Kontrolli erandeid iga 10 sekundi järel
      baseEjectionTime: 60s  # Eemalda host 60 sekundiks
      maxEjectionPercent: 50 # Eemalda maksimaalselt 50% hostidest

            

              
                Copy
              
            
          

Selles näites:

• consecutive5xxErrors: 5: Kaitselüliti rakendub, kui see tuvastab 5 järjestikust HTTP 5xx viga `product-catalog` teenuselt.
• interval: 10s: Envoy proksi teostab erandite tuvastamise kontrolle iga 10 sekundi järel.
• baseEjectionTime: 60s: Kui host eemaldatakse, eemaldatakse see koormuse tasakaalustamise kogumist vähemalt 60 sekundiks.
• maxEjectionPercent: 50: Et vältida ühe ebatervisliku instantsi ülekoormamist tuvastamisel, saab igal ajahetkel eemaldada kuni 50% instantsidest.

Kui kaitselüliti rakendub, lõpetavad Istio Envoy proksid liikluse saatmise `product-catalog`i ebaõnnestuvatele instantsidele `baseEjectionTime` ajaks. Pärast seda perioodi saadetakse väike alamhulk päringuid teenuse kättesaadavuse testimiseks. Kui see õnnestub, sulgub vooluring; vastasel juhul jääb see avatuks.

Linkerdi kasutamine kaitselülitite jaoks

Linkerd pakub samuti robustseid kaitselülituse võimekusi, mida sageli konfigureeritakse selle poliitikaressursside kaudu. Linkerdi kaitselülitus põhineb peamiselt ühendusevigade ja HTTP staatuskoodide tuvastamisel.

Linkerdi kaitselülitus on sageli vaikimisi lubatud või seda saab konfigureerida lüüsipoliitikate kaudu. Oluline on see, kuidas see automaatselt tuvastab ebatervislikud lõpp-punktid ja lõpetab neile liikluse saatmise. Linkerdi telemeetria ja tervisekontrollid on selle kaitselülitusmehhanismi lahutamatu osa.

Üldised kaalutlused Frontend Service Meshi kaitselülitite kohta

• API lüüsi integreerimine: Kui teie frontend service mesh on API lüüs (nt Traefik, Kong, Ambassador), konfigureerige kaitselülituspoliitikad otse lüüsil, et kaitsta oma sisemisi teenuseid väliste päringute tulva eest ja sujuvalt degradeerida vastuseid, kui taustateenused on ebatervislikud.
• Kliendipoolne vs. proksipoolne: Kuigi teenustevõrgud rakendavad tavaliselt kaitselüliteid proksipoolel (sidecar muster), pakuvad mõned teegid kliendipoolseid implementatsioone. Teenustevõrguga hallatavate mikroteenuste arhitektuuride puhul on proksipoolne kaitselülitus järjepidevuse ja kliendikoodi keerukuse vähendamise tõttu üldiselt eelistatud.
• Rikke tuvastamise mõõdikud: Kaitselüliti tõhusus sõltub täpsest rikke tuvastamisest. Konfigureerige kaitselüliti jälgimiseks sobivad mõõdikud (nt HTTP staatuskoodid nagu 5xx, ühenduse ajalõpud, latentsuse lävendid).
• Sujuva degradeerumise strateegiad: Mis juhtub, kui kaitselüliti rakendub? Kutsuval teenusel on vaja strateegiat. See võib hõlmata vahemälus olevaid andmeid, vaikimisi vastust või taotletud andmete lihtsustatud versiooni tagastamist.

Frontend Service Meshi kaitselülitite peamised eelised

Kaitselülitite rakendamine oma frontend service meshis pakub mitmeid eeliseid vastupidavate globaalsete rakenduste ehitamiseks:

1. Parem rakenduse stabiilsus ja usaldusväärsus

Peamine eelis on ahelrikete vältimine. Rikkis teenuste isoleerimisega tagab kaitselüliti, et ühe komponendi rike ei vii kogu süsteemi rivist välja. See parandab dramaatiliselt teie rakenduse üldist kättesaadavust ja usaldusväärsust.

2. Parem kasutajakogemus

Kui teenus pole kättesaadav, kogeb kasutaja viga. Kaitselülitite ja sujuva degradeerumisega saate pakkuda kasutajatele andestavamat kogemust, näiteks:

• Aegunud andmed: Varem vahemällu salvestatud andmete kuvamine vea asemel.
• Vaikimisi vastused: Üldise, kuid funktsionaalse vastuse pakkumine.
• Vähendatud latentsus: Kiiremad veateated või degradeeritud funktsionaalsus võrreldes ajalõpuga päringu ootamisega.

See 'sujuv degradeerumine' on sageli eelistatavam kui rakenduse täielik ebaõnnestumine.

3. Kiirem riketest taastumine

Vältides pidevaid päringuid ebaõnnestuvale teenusele, annavad kaitselülitid sellele teenusele hingamisruumi taastumiseks. Pooleldi avatud olek testib arukalt taastumist, tagades, et teenused integreeritakse liiklusesse tagasi niipea, kui need taas terveks saavad.

4. Efektiivne ressursside kasutamine

Kui teenus on ülekoormatud või ei reageeri, tarbib see väärtuslikke ressursse kutsuvates teenustes. Kaitselülitid hoiavad selle ära, peatades päringud ebaõnnestuvale teenusele, kaitstes seeläbi ülesvoolu komponentide ressursse.

5. Lihtsustatud arendus ja hooldus

Vastupidavusprobleemide delegeerimine teenustevõrgule tähendab, et arendajad saavad keskenduda ärilise väärtuse loomisele. Taristukiht tegeleb keerulise rikkehaldusega, mis viib puhtamate koodibaaside ja vähenenud hoolduskuludeni.

6. Jälgitavus ja monitooring

Teenustevõrgud pakuvad olemuselt suurepärast jälgitavust. Kaitselüliti olek (avatud, suletud, pooleldi avatud) muutub oluliseks jälgitavaks mõõdikuks. Nende olekute visualiseerimine armatuurlaudadel aitab operatsioonimeeskondadel kiiresti tuvastada ja diagnoosida probleeme hajutatud süsteemis.

Parimad tavad Frontend Service Meshi kaitselülitite rakendamiseks

Kaitselülitite efektiivsuse maksimeerimiseks kaaluge järgmisi parimaid tavasid:

1. Alustage mõistlike vaikeväärtustega ja häälestage

On ahvatlev seada agressiivseid lävendeid, kuid see võib viia enneaegse kaitselüliti rakendumiseni. Alustage konservatiivsete väärtustega ja jälgige süsteemi käitumist. Reguleerige lävendeid järk-järgult vastavalt täheldatud jõudlusele ja rikkemustritele. Tööriistad nagu Prometheus ja armatuurlauad nagu Grafana on siin veamäärade ja kaitselülitite olekute jälgimiseks hindamatud.

2. Rakendage sujuva degradeerumise strateegiad

Rakendunud kaitselüliti on vaid osa lahendusest. Määratlege selged tagavaramehhanismid juhuks, kui teenus pole kättesaadav. See võib hõlmata:

• Vahemälu kasutamine (Caching): Aegunud andmete serveerimine vahemälust.
• Vaikimisi väärtused: Eelnevalt määratletud vaikeväärtuste tagastamine.
• Lihtsustatud vastused: Andmete alamhulga või vähem funktsioonirikka vastuse pakkumine.
• Kasutaja tagasiside: Kasutaja teavitamine, et mõned funktsioonid võivad olla ajutiselt kättesaamatud.

Mõelge, kuidas need degradeerumisstrateegiad vastavad teie rakenduse ärinõuetele.

3. Jälgige hoolikalt kaitselülitite olekuid

Teie kaitselülitite olek on süsteemi tervise juhtiv indikaator. Integreerige kaitselülitite mõõdikud oma monitooringu- ja hoiatussüsteemidesse. Peamised jälgitavad mõõdikud on:

• Rakendunud kaitselülitite arv.
• Aeg, mil vooluringid püsivad avatud.
• Edukate/ebaõnnestunud katsete arv pooleldi avatud olekus.
• Rakendumist põhjustavate spetsiifiliste veatüüpide (nt 5xx vigade) määr.

4. Konfigureerige sobivad eemaldamisajad

baseEjectionTime (või samaväärne) on kriitiline. Kui see on liiga lühike, ei pruugi ebaõnnestuval teenusel olla piisavalt aega taastumiseks. Kui see on liiga pikk, võivad kasutajad kogeda kättesaamatust kauem kui vajalik. Seda parameetrit tuleks häälestada vastavalt teie teenuste ja nende sõltuvuste oodatavale taastumisajale.

5. Mõistke oma teenuste sõltuvusi

Kaardistage oma teenuste sõltuvused. Tuvastage kriitilised teenused, mille rike avaldaks olulist mõju. Prioritiseerige kaitselülitite rakendamist nendele teenustele ja nende otsestele sõltlastele. Teenuste sõltuvuste kaardistamise tööriistad teie teenustevõrgus võivad olla väga kasulikud.

6. Eristage ajutisi ja püsivaid rikkeid

Kaitselüliti muster on kõige tõhusam ajutiste rikete vastu (nt ajutised võrgutõrked, lühiajalised teenuse ülekoormused). Püsivate, taastumatute rikete puhul võite vajada erinevaid strateegiaid, näiteks kaitselüliti 'jõuga sulgemise' mehhanisme (ettevaatlikult) või teenuse kohest kasutuselt kõrvaldamist.

7. Arvestage globaalset jaotust ja latentsust

Globaalselt hajutatud rakenduste puhul on võrgu latentsus oluline tegur. Kaitselüliti ajalõpud tuleks seada sobivalt, et arvestada oodatavaid võrguviivitusi piirkondade vahel. Samuti kaaluge piirkondlikke kaitselüliteid, kui teie arhitektuur on mitme piirkonnaga, et isoleerida rikked konkreetses geograafilises piirkonnas.

8. Testige oma kaitselüliti implementatsiooni

Ärge oodake tootmisintsidenti, et avastada, et teie kaitselülitid ei tööta ootuspäraselt. Testige regulaarselt oma kaitselüliti konfiguratsioone, simuleerides rikkeid testkeskkonnas. See võib hõlmata tahtlikku vigade tekitamist testteenuses või tööriistade kasutamist latentsuse ja pakettide kao süstimiseks.

9. Koordineerige taustasüsteemi meeskondadega

Kaitselülitid on koostööprojekt. Suhelge meeskondadega, kes vastutavad kaitstavate teenuste eest. Nad peavad olema teadlikud kaitselüliti konfiguratsioonidest ja oodatavast käitumisest rikete ajal. See aitab neil ka probleeme tõhusamalt diagnoosida.

Levinud lõksud, mida vältida

Kuigi võimsad, ei ole kaitselülitid imerohi ja neid saab valesti kasutada:

• Liiga agressiivsed seaded: Liiga madalate lävendite seadmine võib viia tarbetu rakendumiseni ja mõjutada jõudlust isegi siis, kui teenus on enamasti terve.
• Tagavaralahenduste ignoreerimine: Rakendunud kaitselüliti ilma tagavarastrateegiata viib halva kasutajakogemuseni.
• Pimesi vaikeväärtustele lootmine: Igal rakendusel on unikaalsed omadused. Vaikeväärtused ei pruugi olla teie konkreetse kasutusjuhtumi jaoks optimaalsed.
• Monitooringu puudumine: Ilma korraliku monitooringuta ei tea te, millal kaitselülitid rakenduvad või kas need taastuvad.
• Põhipõhjuste ignoreerimine: Kaitselülitid on sümptomite haldaja, mitte põhipõhjuste parandaja. Nad varjavad probleeme, mitte ei lahenda neid. Veenduge, et teil on protsessid aluseks olevate teenuseprobleemide uurimiseks ja parandamiseks.

Põhilisest kaitselülitusest edasi: täiustatud kontseptsioonid

Kui teie rakenduse keerukus kasvab, võite uurida täiustatud kaitselüliti konfiguratsioone ja seotud vastupidavusmustreid:

• Päringute piiramine (Rate Limiting): Sageli kasutatakse koos kaitselülititega. Kui kaitselülitid peatavad kutsed, kui teenus ebaõnnestub, siis päringute piiramine kontrollib teenusele lubatud päringute arvu sõltumata selle tervisest, kaitstes seda ülekoormuse eest.
• Vaheseinad (Bulkheads): Isoleerib rakenduse osad eraldi ressursikogumiteks, nii et kui üks osa ebaõnnestub, jätkab ülejäänud rakendus toimimist. See sarnaneb kaitselülitusega, kuid ressursikogumi tasemel.
• Ajalõpud (Timeouts): Võrgupäringutele selgesõnaliste ajalõppude seadmine on fundamentaalne rikke vältimise vorm, mis täiendab kaitselüliteid.
• Korduskatsed (Retries): Kuigi kaitselülitid takistavad kutseid ebaõnnestuvatele teenustele, saavad hästi konfigureeritud korduskatsed hakkama ajutiste võrguprobleemide ja teenuse ajutise kättesaamatusega. Kuid liigsed korduskatsed võivad rikkeid süvendada, seega tuleb neid kasutada mõistlikult, sageli eksponentsiaalse ooteajaga.
• Tervisekontrollid (Health Checks): Teenustevõrgu aluseks olevad tervisekontrolli mehhanismid on üliolulised ebatervislike instantside tuvastamiseks, millele kaitselüliti seejärel reageerib.

Globaalsed rakendused ja Frontend Service Meshi kaitselülitid

Kaitselülituse põhimõtete tähtsus võimendub globaalselt hajutatud rakendustega tegelemisel. Arvestage neid globaalseid aspekte:

• Piirkondlik isoleerimine: Mitme piirkonnaga juurutuses ei tohiks rike ühes piirkonnas ideaalis mõjutada teiste piirkondade kasutajaid. Frontend service meshi kaitselülitid, mis on konfigureeritud iga piirkonna sisenemispunktides, saavad seda isolatsiooni jõustada.
• Piirkondadevahelised sõltuvused: Kui eri piirkondade teenused sõltuvad üksteisest, muutuvad kaitselülitid veelgi kriitilisemaks. Rike piirkondadevahelises kutses võib olla eriti kulukas suurema latentsuse ja võimalike võrgupartitsioonide tõttu.
• Varieeruvad võrgutingimused: Globaalsed võrgud on olemuselt ettearvamatumad. Kaitselülitid aitavad neid variatsioone absorbeerida, vältides korduvaid rikkeid ebausaldusväärsete ühenduste kaudu.
• Vastavus ja andmete suveräänsus: Mõnel juhul peavad globaalsed rakendused järgima konkreetseid andmete asukoha regulatsioone. Kaitselüliti konfiguratsioone saab kohandada nende piirangute austamiseks, tagades, et liiklust suunatakse ja hallatakse asjakohaselt.

Rakendades frontend service meshi kaitselüliteid, ehitate robustsema, kohanemisvõimelisema ja kasutajasõbralikuma rakenduse, mis suudab vastu pidada hajutatud ja globaalse võrgusuhtluse olemuslikele ebakindlustele.

Kokkuvõte

Frontend Service Meshi kaitselüliti on asendamatu muster igale organisatsioonile, kes ehitab keerukaid, hajutatud ja globaalseid rakendusi. Abstraheerides vastupidavusprobleemid taristukihti, annavad teenustevõrgud arendajatele võimaluse keskenduda innovatsioonile, tagades samal ajal, et nende rakendused jäävad stabiilseks, reageerimisvõimeliseks ja usaldusväärseks isegi vältimatute rikete korral. Selle mustri valdamine tähendab süsteemide ehitamist, mis mitte ainult ei toimi, vaid degradeeruvad sujuvalt, taastuvad ja püsivad, pakkudes lõppkokkuvõttes paremat kogemust kasutajatele kogu maailmas.

Võtke kaitselüliti muster oma teenustevõrgu strateegia osaks. Investeerige robustsesse monitooringusse, määratlege selged tagavaramehhanismid ja häälestage pidevalt oma konfiguratsioone. Seda tehes sillutate teed tõeliselt vastupidavale mikroteenuste arhitektuurile, mis on võimeline vastama kaasaegse digiajastu nõudmistele.